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1 .  INTRODUCTION 


The  imminent  need  for  security  in  the  real  world  has  led  to  the  development  of  many 
systems.  These  applications  range  from  Coast  Patrolling  mechanisms  to  Network 
Management  protocols.  There  is  a  need  to  continually  monitor  these  applications,  which  may 
not  be  possible  at  all  times.  For  example,  radar  personnel  in  a  military  environment  has  to 
constantly  monitor  air  traffic  and  inform  superiors  if  any  hostile  planes  are  tracked. 
Alternately,  the  Event-Condition- Action  paradigm  can  be  applied  to  monitor  the  radar  and 
respond  to  events  without  any  user  or  application  intervention. 

The  Event-Condition- Action  rule  consists  of  three  components,  namely,  an  event,  a  condition 
and  an  action.  An  event  is  an  instantaneous,  atomic  occurrence  of  interest  at  a  specific  point 
in  time.  The  condition  part  of  the  rule  checks  the  state  of  application  object  and  is  evaluated 
according  to  the  context  of  occurrence  of  the  event.  The  action  describes  the  task  to  be 
carried  out  by  the  rule.  When  an  event  occurs,  the  corresponding  rule  is  triggered  and  the 
condition  is  evaluated.  If  the  condition  evaluates  to  true,  the  corresponding  action  is  taken. 
Considering  the  radar  personnel  example  again,  the  event  can  be  defined  as  the  appearance  of 
a  new  plane  and  the  condition  as  the  plane  belonging  to  a  hostile  country  or  unidentified  and 
the  action  can  be  that  of  informing  the  superiors  in  a  predefined  manner.  This  way,  the  radar 
can  be  constantly  monitored  using  the  ECA  rules  and  it  responds  to  the  events  automatically. 

1.1.  Background 

A  Eocal  Event  Detector  (EED)  [1]  has  been  developed  which  is  based  on  the  Event- 
Condition- Action  rule  paradigm.  It  provides  active  capability  to  various  applications 
including  relational  database  systems.  It  uses  flexible  and  expressive  event  specification 
along  with  well-defined  semantics  provided  by  the  SNOOP  event  specification  language  [2, 
3].  It  is  well  suited  for  monitoring  complex  changes  within  an  application. 

EED  is  an  event  detector  implemented  to  detect  events  and  execute  rules  based  on  those 
events.  It  is  capable  of  handling  events  local  to  an  application.  It  can  detect  primitive  and 
composite  events  and  define  rules  at  class  and  instance  levels.  The  event  detector  processes 
the  event  occurrences  asynchronously  from  the  application.  It  provides  an  option  to  create 
rules  with  different  priorities,  and  the  rule  with  the  highest  priority  being  executed  first. 

Rules  with  the  same  priority  are  executed  concurrently.  The  application  uses  EED  as  a 
library  and  invokes  the  EED  API’s  to  create,  raise  events  and  create  rules. 

1.2.  Eocus  of  the  paper 

Current  EED  implementation  supports  the  creation  of  events  and  rules  at  compile  time.  It 
uses  the  conventional  Edit/Compile/Execute  paradigm.  This  has  several  drawbacks:  once  the 
application  has  started  execution,  modifications  to  existing  rules  and  events  in  the  application 
are  difficult.  In  real-life  monitoring  applications,  during  execution  there  may  be  a  need  to 
create  new  rules  and  events.  At  present,  the  only  way  to  make  changes  is  to  rewrite/add  code, 
recompile,  and  re-execute  it.  This  is  not  desirable  for  many  applications  where  the  previously 
defined  rules  may  need  to  be  refined  or  new  rules  added  without  bringing  the  system  down. 
One  application  that  has  been  developed  for  the  Navy  is  a  track  monitoring  system.  This 
application  uses  a  customized  rule  editor  to  create  a  few  rules  that  have  been  built  into  the 
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editor.  The  rule  editor  eontains  all  the  rules  that  were  known  to  oeeur  during  the  lifeeyele  of 
the  applieation.  For  example,  one  of  the  rules  defined  is  “When  the  speed  of  any  traek  is 
greater  than  700  mph  and  is  present  in  a  speeifie  region  termed  as  Area  of  interest,  update  the 
display  of  the  GUI  with  the  status  of  the  traek”.  The  user  eould  ereate  only  those  rules  that 
are  built  into  the  rule  editor.  As  a  result  the  user  is  restrieted  in  the  types  of  rules  that  ean  be 
ereated.  If  the  user  needs  to  ereate  new  rules  then  this  rule  logie  has  to  be  added  to  the  rule 
editor,  the  applieation  has  to  be  reeompiled  and  reloaded  for  the  new  rule  to  be  available.  The 
applieations  some  times  require  that  the  eonditions  be  ehanged/updated  due  to  ehanges  in  the 
run  time  environment.  For  example,  for  the  above-mentioned  rule,  the  eondition  may  have  to 
be  fine  tuned  to  600  mph  instead  of  VOOmph.  If  the  edit/eompile/exeeute  paradigm  is  used 
then  the  eode  has  to  be  edited,  eompiled  and  reloaded.  Instead  if  the  interaetive/dynamieally 
modify  paradigm  is  used  then  as  soon  as  the  eondition  is  modified  the  ehange  is  visible  to  the 
applieation  and  LED  as  well  and  as  a  result  the  rule  is  modified.  Therefore  the 
interaetive/dynamieally  modify  paradigm  is  better  suited  for  applieations  that  eannot  be 
interrupted  to  make  modifieations. 

For  many  applieations  sueh  as  the  traek  monitor  for  the  Navy,  and  others  (e.g.  Stoek,  trading 
applieation)  there  is  a  need  to  add  events  and  rules  without  using  the  edit/eompile/exeeute 
eyele  normally  used  for  software  development.  It  is  neeessary  to  ehange  or  fine-tune  the 
eonditions  on  the  fly.  Henee,  an  interaetive,  easy-to-use  interfaee  was  needed  to  perform  the 
above  tasks  on  the  fly  and  without  stopping  and/or  restarting  the  applieation. 

This  paper  provides  a  flexible  design  and  implements  a  tool  ealled  “Dynamie  Programming 
Environmenf ’,  whieh  has  the  ability  to  ereate  or  modify  the  rules  as  well  as  ereate  new 
eomposite  or  temporal  events  without  interrupting  the  applieation  exeeution.  This  tool 
provides  a  generie  set  of  elasses  to  handle  the  rules  and  user  applieation  has  to  be  only 
eoneerned  about  defining  events  and  raising  them.  The  tool  also  ean  provide  information 
about  the  rules  and  events  in  an  applieation  in  XML  format.  This  provides  for  persistenee,  so 
that  the  next  time  around  a  user  applieation  ean  revert  to  the  same  state  (events  and  rules 
defined)  when  exeeution  was  stopped. 

2.  RELATED  WORK 

This  seetion  reviews  the  related  work  in  the  area  of  the  EGA  paradigm  and  business  rule 
engines  that  ereate  new  rules  and  events  dynamieally  and  allow  modifieations  to  the  rules. 

2.1.  WebEogie  Events 

WebEogie  Events  [4]  is  an  event  management  system  using  a  publish/subseribe  paradigm 
from  WebEogie.  It  allows  an  event  of  interest  (topie)  to  be  registered  aeross  the  network  by 
any  WebEogie  applieation.  The  WebLogie  Server  matehes  the  oeeurrenee  of  events  with 
registered  events  of  interest.  When  WebEogie  reeeives  an  event  that  matehes  the  registration, 
it  exeeutes  a  user-written  evaluate  (or  eondition)  method  and  based  on  the  outeome,  will 
exeeute  a  user-written  aetion  method. 

Event  registrations  are  stored  in  a  Topie  Tree,  whieh  is  eentral  to  this  arehiteeture.  It  is  a 
hierarehieal,  n-ary  tree  of  period-separated  words  where  eaeh  node  represents  a  partieular 
level  in  tree.  Eaeh  level  in  the  hierarehy  represents  a  greater  level  of  speeifieity;  for  example. 
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a  topic  about  the  city  weather  in  Dallas  is  represented  using  the  notation  as 
“weather. northamerica.us. texas. dallas” .  The  whole  event  service  flows  through  the  topic 
tree.  When  an  event  is  published  by  an  application,  it  trickles  down  the  topic  tree  until  it 
reaches  the  registration  corresponding  to  the  topic.  When  an  event  matches  a  registration,  the 
registration’s  ‘evaluate’  method  is  called  and  if  the  results  from  the  evaluate  method  are 
successful  then  the  ‘action’  method  is  called.  The  ‘evaluate’  and  ‘action’  methods  correspond 
to  the  condition  and  action  parts  of  the  rule.  Since  a  registration  is  associated  with  a  single 
evaluate  and  action  pair  only  a  single  rule  can  be  defined  where  as  multiple  rules  can  be 
defined  on  an  event  in  LED. 

The  possible  groups  of  operation  on  a  Topic  Tree  are: 

•  EventRegistration:  An  application  registers  interest  in  a  particular  topic  by  sending  an 
Event  Registration  to  WebLogic  operations. 

•  EventMessage:  Any  application  on  the  network  can  generate  an  event  for  a  particular 
topic,  by  sending  an  Event  Message  to  WebEogic. 

The  topic  tree  is  dynamically  built  inside  the  WebLogic  Server  as  clients  subscribe  to  Event 
Topics.  When  a  client  subscribes  to  an  event  topic  that  does  not  exist  then  a  new  node  and 
new  branches  to  reach  that  node  are  constructed  in  the  topic  tree.  Now,  when  this  event  is 
published,  the  subscribing  clients  will  receive  notifications.  The  leaf  nodes  in  the  topic  tree 
correspond  to  events  and  all  intermediate  nodes  are  used  for  branching  conditions.  All  the 
leaf  nodes  correspond  to  primitive  events  and  there  is  no  mechanism  to  combine  the 
primitive  events  to  form  composite  events. 

The  WebLogic  Event  Server  provides  communication  between  applications  via  subscribe  and 
publish  paradigm.  When  a  client  subscribes  to  an  event  on  a  WebEogic  server,  it  can  specify 
extra  conditions  that  must  be  satisfied  before  an  event  is  forwarded  to  it.  This  is  achieved  via 
an  evaluator  that  runs  on  the  server.  The  evaluator  checks  the  conditions  specified  by  the 
client  before  forwarding  the  event  to  the  client.  The  event  action()  method  executes  either  at 
the  server  or  the  client.  WebEogic  also  supports  event  parameters  as  a  set  of  name-value 
pairs  that  further  qualify  the  event.  An  event  is  submitted  to  the  server  with  a  set  of  event 
parameters. 

In  WebEogic  server,  it  is  not  possible  to  change  the  evaluate  methods  once  it  is  registered. 
That  is  one  cannot  modify  the  rule  once  the  event,  condition  and  action  methods  have  been 
registered. 

2.2.  ILOG  JRules 

The  software  lEOG  JRules  [5]  is  one  of  the  fastest,  compact  and  robust  rule  engines  in  the 
market.  It  includes  a  rule  engine  for  the  Java  platform,  a  rule  language  with  support  for 
business  rules  and  the  rule  kit  -  a  set  of  tools  supporting  the  development  of  business  rule 
applications. 

2.2.1.  Rule  Engine 

It  is  a  Java  class  that  can  be  implemented  directly  or  derived  from  to  add  application  specific 
data  members  and  methods.  It  provides  flexible  API’s  for  the  developer  to  have  complete 
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control  over  the  engine.  The  rules  ean  be  dynamieally  added  on  the  fly,  modified  or  removed 
from  the  engine  without  shutting  down  or  reeompiling  the  applieation. 

2.2.2.  Rule  Language 

Rules  may  be  represented  in  Java-like  syntax  of  ILOG  rule  language  or  in  XML  or  in  a 
readable  syntax  ealled  a  business  rule  language.  They  provide  full  support  of  java  operators 
in  expressions.  They  also  support  a  relation  between  objeets  for  a  rule.  It  also  supports  rule 
ereation  for  events  based  on  time.  The  rule  strueture  eonsists  of  the  following  three  parts:  a 
header,  a  eondition  part  and  an  aetion  part. 

The  rule  strueture  is  shown  below: 

rule  ruleName  {  [priority  =  value;  ]  [  paeket  =  paeketName;  ] 
when  {  eonditions  . . . } 
then  {  [aetions  ...]  }}; 

The  header  defines  the  name  of  the  rule,  its  priority  and  paeket  name.  The  eondition  part 
begins  with  keyword  when,  and  is  also  referred  to  as  the  left-hand-side  (LHS)  of  the  rule.  It 
defines  the  eonditions  that  must  be  met  in  order  for  the  rule  to  be  eligible  for  exeeution.  The 
aetion  part  is  referred  to  as  the  right-hand  side  (RHS)  of  the  rule.  When  all  of  the  LHS 
eonditions  are  met,  the  RHS  of  the  rule  is  exeeuted  (or  fires).  A  rule’s  priority  eontrols  the 
sequenee  of  the  rule  exeeution.  The  paeket  name  assoeiates  a  rule  with  a  rule  paeket.  Paekets 
provide  a  way  of  grouping  of  related  rules.  The  paekets  ean  be  aetivated/deaetivated  through 
rule-engine  API  or  the  Rule  Language  itself 

2.2.3.  Rule  Kit: 

The  rule  kit  eontains  a  eommon  set  of  tools  delivered  with  ILOG  JRules.  It  features  an 
integrated  development  environment,  rule-editing  eapabilities  and  business  rule  language 
support  for  business  level  representation  of  rules.  When  used  with  JRules  repository,  the  rule 
kit  provides  all  features  neeessary  to  ereate  a  rule  management  environment,  namely 
meehanism  to  ereate,  edit,  maintain,  debug,  and  deploy  business  rules  and  assoeiated  data, 
eustomize  it  to  needs  of  the  applieation.  The  eomponents  of  the  rule  kit  are  briefly  deseribed 
below: 

Rule  Builder:  The  Builder  is  a  graphieal  environment  for  developing  and  debugging  rule 
sets.  It  manages  projeets,  provides  a  set  of  sophistieated  editors  to  ereate  and  modify  rules, 
and  has  integrated  debugging,  inspeetion  and  traeing  tools  to  simplify  the  proeess  of 
developing  and  debugging  a  business  rule  applieation. 

Rule  Editors:  The  Rule  Kit  enables  developers  as  well  as  end  users  to  modify  rules  by 
providing  a  flexible  rule  editor  eomponent  that  ean  add  (aets  as  a  plug-in  to  add)  business 
rule  editing  eapabilities  to  any  Java  applieation.  It  is  a  point  and  eliek  interfaee  that  ean  be 
used  to  ereate  or  edit  syntax  that  business  people  ean  use  and  understand. 

Business  Rule  Language:  It  uses  a  business  voeabulary  and  allows  reasoning  on  an  objeet 
model  that  re  fleets  the  strueture  of  the  business  domain,  rather  than  underlying  Java 
implementation.  It  ean  be  made  as  simple  or  eomplex  as  neeessary,  providing  business  users 
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with  the  freedom  of  ereating  eomplex  rules  or  constraining  them  to  work  within  a  predefined 
scope  of  business  domain. 

2.2.4.  Rule  Repository: 

ILOG  Rules  persist  business  rules  and  all  relevant  business  data  in  a  structure  called 
“repository”.  The  repository  is  the  central  place  for  an  application’s  business  rules  data  and  is 
much  more  efficient  than  traditional  file  based  persistence  schemes.  The  overview  of  the 
structure  of  business  rules  repository  is  shown  below  in  Figure  1.  Business  rules  are 
organized  into  packages  that  can  be  nested  to  any  arbitrary  depth,  which  allows  one  to 
structure  a  project  in  a  way  that  is  closer  to  the  logic  of  the  application.  Also,  a  project  is  a 
collection  of  references  to  packages  and  libraries  of  the  repository.  The  libraries  contain  the 
data  that  is  used  through  out  business  rules,  rule  language  and  rule  templates. 


Figure  1.  The  ILOG  Business  Rule  Repository  structure 

2.2.5.  Working  Memory  and  Context 

When  an  ILOG  rule  engine  is  integrated  into  an  application,  part  of  its  function  is  to  monitor 
the  state  of  various  application  objects.  This  is  necessary,  as  rules  will  typically  reference 
application  objects  in  the  condition  part  of  their  logic.  Working  memory  is  where  ILOG 
JRules  stores  references  to  all  of  the  objects  with  which  it  is  currently  working. 

Rules  are  grouped  into  sets.  Rules  in  a  rule  set  and  the  application  objects  that  they  reference 
are  associated  by  what  is  called  a  context.  That  is,  a  context  associates  rules  with  working 
memory  and  implements  the  rule  engine  that  controls  the  relationship  between  the  two. 

2.2.6.  ILOG  Rule  Engine 

An  ILOG  Rule  Engine  is  integrated  into  an  application  by  simply  having  the  application 
instantiate  an  IlrContext  object,  which  creates  a  rule  engine.  Eormally,  this  instantiation 
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creates  a  eontext.  The  eontext  assoeiates  a  rule  set  with  working  memory  and  implements  a 
rule  engine  that  eontrols  the  relationship  between  the  two. 


■  LOG  Rule  Engine 


r 

A 

Working  Memory 

V 

r 

Rule  Set 

) 

Agenda 


Context 


Figure  2  Context 


The  IlrContext  eonstruetor  ereates  a  rule  set  eontainer,  working  memory,  a  rule  engine,  and  a 
eontext  to  eontrol  it  all.  The  final  step  in  setting  up  the  rule  engine  is  adding  rules  to  the  rule 
set  eontainer.  The  rule  engine  is  now  ready  to  examine  working  memory,  matehing  objeets 
refereneed  in  working  memory  against  patterns  found  in  the  rule  eonditions  and  plaeing  rule 
instanees  in  the  agenda.  The  agenda  is  a  eontainer  that  stores  rule  instanees  that  are  ready  to 
be  exeeuted.  The  rules  are  fired  onee  the  fireAllRules  method  is  ealled  on  the  IlrContext 
objeet.  Onee  the  rule  fires,  it  will  be  removed  from  the  agenda  and  does  not  fire  again. 

JRules  is  not  based  on  aetive  teehnology;  the  only  event  it  provides  is  the  temporal  event.  But 
it  is  a  powerful  business  rule  engine  that  is  widely  used. 

2.3.  Vitria  BusinessWare  Proeess  Automator 

The  Proeess  Automator  in  Vitria  BusinessWare  [6]  provides  a  modeling  environment  that 
eaptures  business  objeets,  events,  rules  and  proeesses  and  uses  them  to  build  a  oolleetion  of 
business  polieies.  It  ineorporates  four  modeling  teehniques  into  an  integrated  proeess- 
development  environment:  business  objeet  models,  business  event  models,  business  proeess 
(or  state)  models  and  business  rules.  It  uses  a  graphieal  modeling  language  to  ereate  proeess 
eharts  that  deseribes  the  different  stages  of  a  business  proeess.  Proeess  eharts  use  graphieal 
elements  to  deseribe  proeesses  in  terms  of  diserete  states  and  the  eonditions  that  eause  the 
business  objeet  to  move  through  various  stages  of  the  proeess  by  means  of  transition  between 
states.  Business  rules  and  polieies  are  expressed  in  event-eondition-aetion  sequenees.  After 
model  states  and  transitions  are  defined  in  the  proeess  ehart,  the  business  rules  for  the 
proeesses  are  defined  using  a  form  based  editor.  The  rule  editor  is  used  to  speeify  the 
proeessing  eondition  and  aetion  when  a  transition  oeeurs  between  proeess  states.  Thus,  an 
event  is  a  transition  from  one  state  to  another.  A  rule  eondition  eompares  a  proeess  variable 
with  some  value  and  sueh  relational  eomparisons  ean  be  eonneeted  through  logieal  operators. 
The  rule  aetion  invokes  methods  on  proeess  objeets.  It  has  no  support  for  eomposite  events 
and  eontext  based  event  deteetion  unlike  LED.  Also,  rules  eannot  be  speeified  with  a  priority. 
Rule  eonditions  eannot  perform  eomplex  eomputations  unlike  the  Sentinel  system.  Sinee 
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conditions  and  actions  are  implemented  as  methods  in  Sentinel  system,  they  ean  perform  any 
operations  that  are  permissible  in  a  Java  method. 

2.4.  Sentinel 


Sentinel  [7]  [8-11]  is  an  integrated  aetive  DBMS  ineorporating  EC  A  rules  using  the  Open 
OODB  Toolkit  [13]  from  Texas  Instruments.  Event  and  rule  specifications  are  seamlessly 
ineorporated  into  the  C++  language.  Any  method  of  an  objeet  elass  is  a  potential  primitive 
event.  The  event  oeeurs  either  at  the  beginning  of  the  method  or  at  the  end  of  the  method. 
Composite  events  are  defined  by  applying  a  set  of  operators  to  primitive  events  and/or 
eomposite  events.  Events  and  rules  are  speeified  in  a  elass  definition.  In  addition,  Sentinel 
supports  events  and  rules  that  are  speeifie  to  objeet  instanees.  In  that  ease,  events  and  rules 
are  speeified  within  the  program  where  the  instanee  variables  are  deelared.  This  ability  to 
deelare  events  and  rules  outside  of  a  class  allows  for  composing  events  aeross  elasses.  This 
provides  a  major  advantage  to  Sentinel  eompared  to  many  other  aetive  systems. 

The  parameters  of  a  primitive  event  eorrespond  to  the  parameters  of  the  method  deelared  as 
the  primitive  event  and  other  attributes,  such  as  the  time  of  oeeurrence  of  the  event.  The 
proeessing  of  a  eomposite  event  involves  not  only  its  deteetion,  but  also  the  eomputation  of 
the  parameters  assoeiated  with  the  eomposite  event.  The  parameters  of  the  event  are  passed 
onto  eondition  and  action  part  of  a  rule.  The  parameters  assoeiated  with  the  deteetion  of  an 
event  ean  be  different  in  different  contexts.  Sentinel  supports  four  eontexts  namely  reeent, 
ehroniele,  eontinuous,  and  eumulative  eontexts. 

An  event  ean  trigger  several  rules,  and  rule  actions  may  raise  events  that  ean  trigger  other 
rules.  Sentinel  supports  multiple  rule  executions,  nested  rules  exeeutions  as  well  as 
prioritized  rule  executions.  Sentinel  supports  immediate  and  deferred  mode  of  execution. 

A  Dynamic  Rule  Editor  [12]  was  built  to  extend  the  Sentinel  system  to  support 
external/dynamic  rules.  It  provides  a  friendly  environment  to  manipulate  the  rules  without 
ehanging,  reeompiling  or  relinking  any  source  eode  of  their  applieations.  It  has  a  three-tier 
arehiteeture  and  it  consists  of  four  modules  namely  the  interfaee,  the  Rule  Editor  Server,  the 
rule  database  and  the  Dynamie  Rule  Eoader.The  database  logie  was  deeoupled  from  the  Rule 
Editor  Server  by  using  OQL  and  separating  all  the  database  dependent  eode  as  individual 
funetions  to  faeilitate  porting.  In  the  Dynamic  Rule  Eoader  module,  we  used  dynamie 
linking  library  to  invoke  eondition  and  aetion  funetions,  whieh  avoids  the  relinking  of 
applieations. 

3.  DESIGN  OF  DYNAMIC  PROGRAMMING  ENVIRONMENT 

This  ehapter  diseusses  the  issues  eneountered  during  the  design  of  the  arehiteeture  of  DPE, 
identifying  the  information  needed  for  DPE,  ereation  and  modifieation  of  rules,  the  ereation 
of  temporal  and  eomposite  events,  and  finally  persisting  information  for  reusability. 
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3.1.  Approaches  explored 

An  interaetive,  easy  to  use  interfaee  is  required  that  ean  ehange  or  fine-tune  eonditions, 
ereate  new  events  and  rules.  All  these  tasks  need  to  be  aeeomplished  without  reeompiling  or 
restarting  the  applieation.  The  various  approaehes  that  were  explored  to  aoeomplish  the 
above  tasks  are  diseussed  below: 

3.1.1.  Approaeh  1-  Statie  rule  editor 

In  this  approaeh,  a  rule  editor  is  built  for  eaeh  applieation.  Therefore  for  any  other 
applieation  a  new  rule  editor  is  required,  sinee  this  rule  editor  is  speeifie  to  the  applieation. 
Also,  the  user  applieation  ean  be  eonsidered  to  eonsist  of  two  sets  of  elasses;  one  set  used  to 
handle  the  interaetive  data  input,  to  ereate  and  raise  events  and  another  set  of  elasses  to 
maintain  the  semanties  of  the  rules.  In  this  approaeh,  these  two  sets  of  elasses  are  tightly 
eoupled  or  intertwined,  due  to  whieh  it  is  diffieult  to  understand  the  logie  of  the  either  set  of 
elasses  without  understanding  the  other.  This  also  makes  the  management  and  maintenanee 
of  both  these  sets  of  elasses  diffieult. 

3.1.2.  Approaeh  2  -  General  purpose  rule  editor 

A  general-purpose  environment  for  ereation,  modifieation  and  management  of  rules  ean  be 
built  instead  of  building  a  speeifie  rule  editor  for  eaeh  applieation,  as  in  the  previous 
approaeh.  Sinee  it  is  a  general  rule  editor,  it  is  required  to  eustomize  it  so  that  it  ean  be  used 
with  a  speeifie  applieation.  To  eustomize  it,  the  following  tasks  are  to  be  performed.  First  it 
has  to  interfaee  with  the  user  applieation.  It  has  to  aequire  information  that  is  speeifie  to  the 
user  applieation.  Also  it  has  to  handle  the  interfaee  and  domain  speeifie  issues  of  the 
applieation. 

Using  this  approaeh,  "'Dynamic  programming  environment  for  active  rules  (DPEf  was 
designed.  This  approaeh  has  the  following  advantages  as  eompared  to  the  other  approaeh, 
namely:  First,  it  is  applieation  independent  and  henee  ean  be  used  in  eonjunetion  with  any 
applieation.  Seeond,  it  has  an  interaetive  interfaee  to  dynamieally  edit  and  exeeute  EGA 
rules.  Most  importantly,  the  applieation  need  not  be  modified/reeompiled  or  restarted.  The 
applieation  developer  ean  foeus  on  the  applieation  semanties  of  handling  the  data,  ereating 
and  raising  the  primitive  events.  DPE  provides  the  flexibility  to  predefine  some  rules  or  let 
the  DPE  ereate  the  rules  eompletely.  Einally,  the  rules  that  are  defined  by  the  DPE  ean  be 
persisted  and  reused  again. 

The  following  seetions  diseuss  the  various  designs  issues  that  were  eneountered  during  the 
design  of  DPE. 

3.2.  Arehiteeture 

One  of  the  issues  eneountered  while  designing  the  DPE  was  the  handling  of  the  various 
eomponents  (Rule  Editor,  Applieation,  EED)  and  their  integration  without  modifying  their 
eurrent  arehiteeture.  The  arehiteeture  that  was  initially  explored  is  diseussed  following  the 
proposed  arehiteeture. 
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3.2.1.  Initial  Architecture 


The  first  architecture  that  was  considered  is  the  active  application  consisting  of  the  user 
application  and  LED  in  one  address  space  (or  a  single  process).  The  rule  editor  was  in 
another  address  space  (or  as  a  separate  process).  The  architecture  is  as  shown  in  Figure  3 


Processl 


Process! 


Figure  3  Architecture 

This  architecture  is  designed  based  on  the  general-purpose  rule  editor.  It  has  the  advantage  of 
being  application  independent.  But  the  two  address  space  architecture  has  the  following 
disadvantages;  Firstly,  since  the  rules  have  to  be  created  in  the  LED  eventually,  but  managed 
outside  in  the  rule  editor,  Inter-Process  communication  (IPC)  is  required  to  send  objects  from 
the  application  to  the  rule  editor.  Also,  additional  services  have  to  be  implemented  for  each 
application  that  can  send  and  receive  data  in  the  application.  The  overhead  to  create  events  in 
this  approach  is  too  much.  Finally,  there  is  not  much  gain  for  the  complexity  posed  by  this 
architecture.  Another  architecture  was,  therefore,  proposed  due  to  the  disadvantages  in  this 
approach. 

3.2.2.  Proposed  Architecture 

In  this  architecture  all  the  three  components  are  in  a  single  address  space  as  shown  in 
Figure  4.  DPE  is  a  module  that  runs  in  the  same  address  space  as  that  of  the  application  and 
the  LED.  DPE  is  responsible  for  creating  and  modifying  rules  and  for  creating  new  events  at 
run  time  without  recompiling  the  code.  This  is  possible  as  the  DPE  can  now  access  data 
structures  of  FED  through  the  APIs.  The  application  can  send  needed  information  to  the 
DPE  using  a  number  of  APIs  that  are  part  of  the  DPE.  DPE  is  started  as  a  separate  thread  by 
the  application.  The  functional  modules  of  DPE  are  shown  in  Figure  5.  FED  corresponds  to  a 
library  that  has  been  developed  to  declare  events  and  to  execute  associated  rules  when  the 
event  occurs.  The  application  uses  FED  API’s  to  create  and  raise  primitive  events.  The 
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application  provides  necessary  information  to  the  DPE  in  the  form  of  input  configuration  file. 
The  DPE  uses  this  information  to  create  new  rules  and  events  that  are  registered  with  LED. 
The  DPE  aecepts  user  request  and  performs  the  task. 

In  this  arehitecture,  there  is  no  need  for  any  IPC  since  all  the  components  are  in  a  single 
address  space.  The  user  application  has  to  only  invoke  DPE  and  no  other  modification  in  the 
user  application  is  required.  DPE  provides  the  necessary  API’s  to  be  used  by  the  user 
application.  This  architecture  provides  a  clean,  logieal  separation  of  code  required  for  the 
Rule  Editor  and  the  code  developed  for  the  application. 


Config  Config 


Single  Process 

Eigure  4  Proposed  Arehitecture 

3.2.3.  Dynamic  Programming  Environment  (DPE)  functional  modules 

The  funetional  modules  of  DPE  are  as  shown  in  Figure  5.  The  Configuration  Processor 
accepts  the  input  configuration  file,  which  can  either  be  in  XML  format  or  Text  format.  This 
module  parses  the  input  configuration  file  and  initializes  all  the  data  structures  that  contain 
information  required  to  ereate  and  modify  rules,  and  ereate  events.  Once  the  data  structures 
are  initialized,  the  GUI  is  set  up  to  eontain  information  about  the  available  event  domains, 
event  types,  condition  domains,  condition  methods,  attributes,  action  domains  and  finally  the 
action  methods.  After  the  GUI  is  set  up,  the  user  input  is  accepted.  User  request  is  sent  to  the 
module  that  is  responsible  to  create  and  modify  rules,  and  create  events. 
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Figure  5  DPE  Functional  modules 


If  the  request  is  to  create  a  rule,  the  information  corresponding  to  the  new  rule  is  stored 
internally  and  a  rule  is  created  in  LED.  This  rule  is  triggered  when  the  corresponding  event 
occurs.  The  user  can  modify  only  the  rules  that  have  been  created  by  the  DPE.  When  the 
request  is  to  modify  a  rule,  the  user  can  only  modify  the  condition  part  of  the  rule.  When  a 
request  to  modify  a  rule  is  received,  the  information  corresponding  to  this  rule  is  retrieved. 
Now  the  new  condition  information  is  updated  with  the  rule  information.  After  the  update  is 
done,  the  new  condition  is  effective.  If  the  user  request  is  to  create  a  new  event,  then  the 
corresponding  temporal  or  composite  event  is  registered  with  the  LED.  This  new  event 
created  can  be  used  to  create  new  rules. 

The  DPE  contains  a  module  that  generates  a  configuration  file,  which  contains  information 
about  the  events  and  rules  created  by  the  DPE.  It  also  contains  information  about  the  class 
and  events  created  by  the  application.  This  configuration  file  can  be  used  as  input 
configuration  file  to  the  DPE  when  it  is  restarted. 

3.3.  Rule  Editor  Configuration  file 

One  of  the  important  issues  in  the  design  is  how  to  provide  the  application  specific 
information  and  what  is  the  minimal  information  that  would  be  required  from  the  user 
application  so  that  the  rules  and  events  can  be  created  successfully.  The  configuration  file  is 
used  to  provide  application-specific  information  to  the  DPE  and  the  structure  of  the 
configuration  file  is  shown  below  in  Eigure  6. 
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Class:  Name 

InstanceN  aine:  N  ame  s 

Attributes  : N ame, Typ e ,Units ^vent A s s o ci ate d 

ClassLevelPrmiitiveEvent:EventName,methodsignature,  Parameters  to  be  inserted 
InstanceL  evelPunidveE  vent :  Eventinstane  eName  ,EventName  ,methodsignature. 

Parameters  to  be  inserted 

C  omp  ositeE  ventiEventN  ame  ,EventType ,  C  onstitutentEvents  (1  e  ft^ni  ddl  e  ,ri  ght) 

Condition:  MethodSignature 
Action:  MethodSi  gnature 

EmailAction: 

EmailServer: 

FroniAddress: 

EventsCreated: 

CIassLevelPrimitiveEvent:EventName,AbsoluteTimein  the  format  hh:mm:ss/mm/dd/yyyy 
C  omp  ositeE  vent:EventN ame  ,EventType ,  C  onstitutentEvents  (1  e  ft^ni  ddl  e  41  ght) 

Rules  Created: 

ClassRule:RuleEventName,  AetionObjeet,  RuleAetionMethod, Condi tionString 
InstanceRule:  Rul  eEventInstan  e  eN ame,Rul  eEventN ame ,  A  eti  onObj  e  et,Rule Aeti  onMetho  d, 

Conditionstring 
Event  Creation  Messages: 

Figure  6  Structure  of  the  configuration  file 


The  configuration  file  contains  information  about  classes,  new  rules  to  be  created  and  the 
default  action  information  (e.g.,  email)  The  DPE  provides  a  default  action  namely  (Email)  so 
that  it  can  be  used  for  notification  when  a  rule  is  successfully  executed.  The  class  information 
contains  the  instance  names,  the  information  of  events  that  has  been  created  by  the 
application  and  the  events  that  have  to  be  created  by  DPE.  Also,  it  contains  information 
about  the  attributes  that  can  be  used  for  condition  and  the  list  of  conditions  methods.  The 
information  about  the  available  action  methods  is  also  specified.  After  DPE  parses  this 
configuration  file,  it  uses  this  information  to  create  rules  and  events. 

3.4.  Dynamic  Creation  of  Events  and  Rules 

The  next  issue  in  the  design  is  to  interactively  add  events,  rules  and  modify  rules.  To  add 
events  or  rules,  the  objects  are  needed,  which  is  provided  by  the  application  through  the 
configuration  file.  The  objects  provided  by  the  application  are  just  the  references  to  the 
original  objects  and  no  duplicates  are  maintained. 

Applications  that  are  currently  using  EED  have  to  predefine  all  the  events  and  rules. 

Changing  the  rules  at  run  time  would  involve  changing  the  classes  containing  the  rule 
definition  (i.e.,  updating  the  condition  part  of  the  ECA  Rule).  Therefore,  managing  the 
condition  part  is  the  core  issue  of  the  DPE  design  since  the  condition  can  be  changed  at  run¬ 
time.  Currently,  the  condition  is  represented  as  a  method  and  another  representation  is 
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required  sinee  any  update  to  the  method  is  refleeted  only  after  reeompiling  the  applieation. 
Conditions  that  have  attribute  comparisons  can  also  be  represented  as  a  string  instead  of  a 
method,  so  that  when  the  string  is  evaluated  (actually  interpreted  at  runtime)  the  condition  is 
checked  and  any  update  to  the  string  is  effective  immediately.  This  condition  string  is  an 
attribute-based  comparison.  This  representation  is  flexible  and  it  can  also  be  combined  with 
existing  condition  methods.  Also,  the  condition  methods  are  not  appropriate  for  interactive 
use  but  they  can  be  still  used  for  conditions  if  desired.  The  available  types  of  conditions 
currently  supported  in  the  DPE  are;  an  attribute-based  condition  string  (simple  condition), 
execution  of  an  existing  condition  (simple  condition)  and  finally  a  combination  of  the  above 
two  types  (complex  condition). 

Consider  an  example  class  Track  with  two  attributes:  Speed  and  Altitude  and  a  condition 
based  on  these  attributes  represented  as  “Speed  >  700  &&  Altitude  <  20000”.  This  condition 
needs  to  be  evaluated  at  runtime  where  in  the  values  of  the  attributes  “Speed”  and  “Altitude” 
at  that  point  of  time  have  to  be  substituted  and  then  the  resulting  string  is  evaluated.  The 
“Reactive  class”  in  the  LED  package  already  provides  this  capability.  This  class  uses  a 
software  package  “EESI  (Tree  EcmaScript  Interpreter)”  [15]  which  is  an  interpreter 
implemented  in  Java.  Therefore  any  class  that  wants  to  use  attributes  in  the  condition  needs 
to  extend  the  Reactive  class. 

Also,  using  this  approach  a  complex  condition  can  be  created  which  could  contain  many 
simple  condition  strings  (SCS)  connected  by  Boolean  operators.  Therefore  a  class, 
“RuleConditionObject”,  corresponding  to  the  SCS  is  constructed  to  allow  the  following 
functions. 

•  Represent  both  the  predefined  condition  methods  and  condition  strings  constructed  from 
attributes 

•  Evaluate  the  attribute  comparison  string 

•  Execute  a  condition  method  as  a  simple  condition 

All  the  '‘‘RuleConditionObjects  ”  corresponding  to  the  condition  are  contained  in  a 
“ConditionGeneric  ”  class.  Each  rule  created  by  DPE  will  contain  an  instance  of 
“ConditionGeneric  ”  class  as  the  condition  instance.  The  usage  of  "ConditionGeneric  ”  class 
provides  the  flexibility  to  change  the  condition  of  rule  later  and  not  requiring  the  rule  to 
register  the  updated  condition  with  LED  since  only  the  data  members  are  changed  and  no 
new  instance  is  created.  This  class  contains  a  method,  ''condition’',  which  follows  the 
condition  method  requirement  of  the  existing  LED  design.  By  this,  the  structure  required  by 
the  existing  LED  for  condition  method  of  rules  is  retained  and  the  modification  of  rules  at 
run  time  is  allowed.  The  condition  method  evaluates  the  complete  condition  by  first  getting 
the  results  from  each  of  the  RuleConditionObject  and  constructing  a  string,  which  is 
evaluated  by  the  Reactive  class  to  give  the  result,  based  on  which  the  action  part  of  the  rule 
will  be  executed. 

The  available  action  types  are  default  action,  email  and  the  action  methods.  To  create 
instance-level  rules  and  conditions,  the  instances  of  the  classes  are  required.  These  instances 
are  provided  by  the  application  to  the  DPE  directly  and  in  java  objects  are  passed  by 
reference  and  therefore  no  duplicates  are  maintained.  Each  instance  is  named  and  a  mapping 
of  user-defined  names  to  object  references  is  supplied  by  the  application  to  the  DPE  by 
invoking  an  API  provided  by  the  DPE.  Each  instance  is  named  and  a  mapping  of  user- 
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defined  names  to  objeet  referenees  is  supplied  by  the  application  to  the  DPE  by  invoking  an 
API  provided  by  the  DPE. 

3.5.  Rule  Creation 

Rules  can  be  of  two  types:  class  level  and  instance  level  rules  as  described  earlier.  Rule 
creation  is  a  three-step  process  that  comprises  of  event,  condition  and  action  selection. 

3.5.1.  Event  Selection 

Eor  each  event  that  has  been  specified  in  the  DPE  configuration  file,  an  instance  of  the  class 
“EventObject”  is  created.  This  instance  will  contain  all  the  information  corresponding  to  the 
event  and  also  the  class  that  defines  the  event.  All  the  “EventObjects  ”  are  stored  in  a  data 
structure.  Events  are  grouped  based  on  the  classes  they  belong  to. 

In  the  DPE,  events  are  selected  in  the  following  way: 

Initially  select  a  class  from  the  list  of  event  classes 

Select  an  instance  of  the  class  as  the  event  instance  if  an  instance  level  rule  is  required 

Select  null  as  the  event  instance  if  a  class  level  rule  is  required 

Einally  select  the  interested  event  present  in  the  selected  class 

A  sample  event  selection  would  be  constructed  as 

“null.  Track.  SpeedEvenf’  or 

“T7001,  Track.EatEongEvent” 

Track  is  the  name  of  the  class  containing  the  events,  “null”  and  “T7001”  refer  to  the  event 
instances  for  a  class  and  instance  level  rule  respectively.  SpeedEvent  and  EatEongEvent  are 
names  of  the  events  selected  from  the  class  Track. 

3.5.2.  Condition  Selection 

The  condition  methods  or  attributes  are  grouped  based  on  the  class  they  belong  to.  A 
condition  is  selected  once  the  event  is  selected.  In  the  DPE  conditions  are  selected  in  the 
following  way: 

Select  a  class  from  the  list  of  condition  classes 
Select  an  object  instance  of  this  class  or  null 

0  When  “null”  is  chosen  as  condition  instance,  then  the  instance  is  internally 
created  and  assigned  when  the  rule  is  executed 
Selects  either  a  condition  method  or  an  attribute 

0  If  an  attribute  is  chosen  then  specify  the  comparison  operator  and  value. 

This  forms  the  SCS,  and  this  selection  process  can  be  repeated  to  add  additional  Boolean 
“AND”  or  “OR”  operators.  The  various  comparison  operators  that  can  be  used  with  the 
attribute  are  detailed  below: 

Normal  Comparison  Operators  used  with  Attributes:  An  attribute  of  a  class  can  be  used 
as  a  part  of  the  SCS  only  if  the  class  is  derived  from  the  “Reactive”  class  present  in  the  EED 
package.  The  attributes  should  be  public  members  of  the  class. 
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Currently  only  two  types  of  attributes  are  supported:  string  or  numeric.  This  is  because  of 
the  limitation  of  regular  expression  evaluator  used  by  the  “eval”  method  of  the  ''Reactive” 
class,  to  compute  the  result  of  comparison  string.  To  this  method  an  attribute  name  along 
with  normal  comparison  operators  and  comparison  value  is  passed.  This  method  replaces  the 
attribute  with  its  value  at  run  time  and  uses  the  evaluator  to  compute  the  result.  Hence  the 
restriction  on  the  attribute  that  it  has  to  be  a  public  member  of  the  class,  so  that  it  can  be 
accessed  directly.  The  result  of  the  evaluator  is  a  Boolean  object,  whose  value  is  returned  by 
the  “eva/”  method. 

An  attribute  of  type  “string”  allows  only  two  comparison  operators  namely  “==  ”  and  “!  = 
Examples  are  shown  below 

“null  ,Track.TrackNumber  ==  “T7000”  TrackNumber” 

“null,  TrackTrackNumber  !=  “T7000”  TrackNumber” 

An  attribute  of  type  “numeric”  would  include  all  data  types  for  integers  and  real 
numbers.  The  possible  comparison  operators  are  “==  !  =,  <,  <=,  >,  and  >  =  ”.  Examples 
are  shown  below: 

“null,  Track.Speed  ==  7000  miles“ 

“null,  Track.Speed  !=  7000  miles“ 

“null,  Track.Speed  >  7000  miles” 

“null,  Track.Speed  >=  7000  miles” 

“null,  Track.Speed  <  7000  miles” 

“null,  Track.Speed  <=  7000  miles” 

Special  Comparison  Operators  with  Attributes:  There  are  some  circumstances  wherein 
the  user  would  like  to  do  special  types  of  comparison,  such  as  to  check  if  the  speed  of  the 
aircraft  has  increased  compared  to  the  previous  value  or  to  check  if  the  altitude  is  decreasing 
compared  to  the  previous  value  or  there  is  no  change  in  the  value  of  certain  attributes. 
Therefore,  some  additional  comparison  operators  for  numeric  attributes  were  introduced. 
These  operators  are  described  below. 

•  Nochange  operator 

This  operator  would  be  used  when  the  user  wants  to  perform  some  action  when  the  value  of  a 
certain  attribute  has  not  changed  compared  to  its  previous  value.  Example  of  a  SC S  using  this 
operator  is  shown  below: 

“null,  Track.Speed  nochange” 

ChangesBy  operator 

There  are  two  ways  this  operator  could  be  used  and  they  are: 

1 .  Changesby  value  unit 

Example:  “null,  Track.Speed  changesby  10  miles”. 

This  denotes  that  the  user  wants  to  check  if  the  speed  has  changed  by  10  miles  compared  to 
its  previous  value. 

2.  Changesby  value  % 

Example:  “null,  Track.Speed  changesby  10  %”. 
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This  denotes  that  the  user  wants  to  perform  an  aetion  when  the  attribute  speed  has  ehanged 
by  10%  eompared  to  its  previous  value 

•  InereasesBy  operator 

The  two  possible  types  are  speeified  below: 

1 .  Inereasesby  value  unit 

Example:  “null,  Traek.  Speed  inereaseby  10  miles” 

This  denotes  that  the  user  wants  to  perform  an  aetion  when  the  value  of  attribute  Speed  has 
inereased  by  10  miles  eompared  to  its  previous  value. 

2.  Inereasesby  value  % 

Example:  “null,  Traek. Speed  inereases  by  10  %” 

This  denotes  that  the  user  wants  to  perform  an  action  when  the  value  of  attribute  Speed  has 
increased  by  10  %  compared  to  its  previous  value. 

•  DecreasesBy  operator 

The  two  possible  types  of  this  operator  are: 

1 .  Decreasesby  value  unit 

Example:  “null,  Track.Speed  decreasesby  15  miles” 

This  denotes  that  the  user  wants  to  perform  an  action  when  the  value  of  the  attribute  Speed 
has  decreased  by  15  miles  compared  to  its  previous  value. 

2.  DecreasesBy  value  unit 

Example:  “null.  Track.  Speed  decreasesby  15  %” 

This  denotes  the  user  wants  to  perform  an  action  when  the  value  of  the  attribute  Speed  has 
decreased  by  15%  compared  to  its  previous  value. 

A  complete  condition  selection  connected  by  Boolean  “&&”  operator  is  as  shown: 

“null.  Track. conditionAltitude”  &&  “T7000,  Track.speed  >  7000  miles” 

3.5.3.  Action  Selection 

Two  kinds  of  action  are  available  for  selection.  An  action  method  and  an  email  option  can  be 
selected  for  the  action  part  of  the  Rule.  In  the  DPE  actions  are  selected  in  the  following  way: 

•  Send  an  email  using  DPE 

•  Recipient’s  email  address  should  be  provided 

•  Other  information  such  as  sender’s  address  and  mail  server  address  necessary  to  send  an 
email  is  provided  in  the  configuration  file. 

•  Select  an  action  method 

•  Select  an  action  class  from  the  list  of  action  classes 

•  Select  an  instance  belonging  to  that  class 

0  Einally  select  one  of  available  action  methods  from  the  selected  class 

The  information  pertaining  to  each  rule  needs  to  be  stored  because  there  is  no  mechanism  in 
the  EED  to  retrieve  this  information  later  for  modifying  the  rule.  Therefore,  a  class 
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'"GeneralRuleObject"  is  used  to  contain  the  details  of  a  rule.  An  instance  of 
'"GeneralRuleObject”  is  created  from  this  information  and  it  internally  contains  a 
“ConditionGeneric”  object  corresponding  to  the  condition.  The  “ConditionGeneric”  object 
in  turn  creates  the  necessary  ^"RuleConditionObjects"  for  each  SCS.  This 
''GeneralRuleObjecf’  is  stored  in  a  data  structure  that  contains  all  the  ''GeneralRuleObjects 
The  “createRule”  API  of  LED  is  invoked  to  register  the  rule  with  the  corresponding  event. 

3.6.  Rule  Modification 

Modifying  the  existing  rules  without  having  to  recompile  the  code  or  to  register  again  with 
LED  was  the  main  driving  force  behind  separating  the  condition  into  SCS,  which  are 
represented  as  ‘'RuleConditionObjects”. 

A  rule  to  be  modified  is  selected  from  the  list  of  rules  created.  The  list  of  rules  consists  of  all 
the  “GeneralRuleObjects  ”  present  in  a  data  structure  that  contains  rules.  Currently  only 
modification  of  the  condition  is  supported.  After  a  rule  is  selected  then  the  condition  of  the 
rule  is  fetched  and  is  presented  to  the  user  for  modification.  The  following  are  the  possible 
ways  of  changing  the  condition  part  of  the  rule; 

•  Changing  the  condition  method 

•  Changing  the  comparison  operator 

•  Changing  the  value  in  an  attribute  comparison  condition  string 

•  Changing  the  attribute  comparison  string 

•  Changing  a  condition  method  to  attribute  comparison  or  vice-versa 

Initially,  different  classes  were  created  to  handle  the  different  types  of  SCS;  one  class  to 
handle  attribute  based  SCS  along  with  a  condition  method  and  another  class  to  handle  special 
comparisons  operators  in  attribute  based  SCS.  But  this  implementation  had  a  problem  during 
rule  modification.  In  rule  modification,  you  can  modify  a  SCS  that  contained  simple 
comparison  operator  to  a  method  containing  a  special  comparison  operator  or  vice-versa.  To 
handle  this  case,  different  objects  need  to  be  created  when  conditions  changed  and  update  the 
“ConditionGeneric  ”  class.  This  was  not  possible  easily  at  run  time  since  the  object  for  the 
old  SCS  had  to  be  deleted  and  a  new  object  for  the  modified  SCS  has  to  be  created.  A  better 
approach  was  needed  where  there  is  no  overhead  due  to  objects  being  deleted  and/or  created. 
Therefore,  only  one  class  is  used  instead  of  two  classes,  and  information  of  the  class  handling 
special  comparison  operator  were  added  to  the  other  class.  In  this  class,  for  attribute  based 
comparison  strings  containing  special  operators,  instead  of  directly  sending  the  string  to  eval 
method  of  the  Reactive  class,  the  SCS  is  evaluated,  to  reduce  the  special  operators  to  normal 
operators  and  is  then  sent  to  the  eval  method  so  that  it  can  evaluate  the  string  properly.  This 
approach  would  prevent  the  creation  of  new  objects  at  run  time  when  condition  is  modified 
and  the  task  of  modifying  the  condition  can  be  accomplished  by  just  setting  the  data 
members  with  updated  values.  There  is  an  additional  flag  present  in  “RuleConditionObject” 
to  differentiate  if  it  is  a  class  or  instance  level  attribute  condition  string  or  it  is  a  condition 
method  in  the  SCS.  This  flag  needs  to  be  updated  accordingly  if  the  condition  object  is 
changed  between  null  and  a  specific  instance  or  if  the  condition  changes  from  an  attribute- 
based  to  method-based  or  vice  versa.  After  all  these  updating  changes  are  done,  the  condition 
is  saved  and  the  rule  has  been  modified  successfully. 
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3.7.  Event  Creation 


When  an  application  is  executing,  apart  from  the  need  to  modify  or  create  rules,  the  user  may 
also  want  to  create  new  events.  Hence  the  ability  to  create  new  temporal  and  composite 
events  is  provided.  New  primitive  events  are  not  provided  as  it  corresponds  to  creation  of 
method  code,  compiling  it  programmatically,  and  loading  the  class  at  run  time.  The  primary 
goal  of  this  editor  is  to  support  creation  of  rules  by  changing  conditions  at  run  time. 

Typically,  we  are  trying  to  avoid  accepting  code  as  part  of  the  interactive  environment, 
although  it  is  possible  to  do  so 

To  create  a  temporal  event,  the  user  should  specify  a  class  to  associate  the  event  to.  After 
selecting  the  class  the  absolute  time  when  the  event  should  be  raised  need  to  be  specified. 
After  this  information  is  collected,  this  event  is  registered  with  the  LED  by  making  a  call  to 
createPrimitiveEvent  of  ECAAgent.  Once  this  event  is  created,  it  is  available  to  the  user  for 
creating  the  rules. 

Composite  events  are  created  by  initially  selecting  an  event  operator  along  with  the  required 
number  of  constituent  events  from  the  list  of  available  events.  The  list  of  event  operators 
consist  of  “AND,  OR,  SEQ,  PLUS,  PERIODIC,  PERIODIC  STAR,  APERIODIC, 
APERIODIC  STAR,  NOT  ”.  Once  the  event  type  is  selected,  they  are  classified  as  either 
binary  or  ternary  operators,  and  then  the  user  chooses  the  corresponding  events.  Eor  PLUS, 
PERIODIC,  PERIODIC  STAR  operators  one  of  the  events  is  the  absolute  time  string.  Once 
all  the  information  required  for  creating  a  composite  event  is  collected,  the  event  is  registered 
with  LED  by  invoking  the  “createCompositeEvent”  API.  The  composite  events  created  are 
associated  with  the  class  called  “Composite”  so  that  the  user  can  look  for  the  composite 
events  created  under  this  class.  Therefore,  the  user  is  provided  with  the  ability  to  create  new 
events  at  run  time. 

3.8.  Persist  created  events  and  rules  to  support  reusability 

When  the  DPE  is  used  with  an  application,  a  number  of  events,  conditions  and  rules  are 
created  interactively.  A  mechanism  is  required  to  input  these  events,  conditions  and  rules  into 
the  system  if  it  were  to  be  restarted.  Otherwise,  the  process  has  to  be  repeated  all  over  again. 
To  accomplish  this,  the  system  can  generate  a  configuration  file  that  can  be  used  as  input  to 
the  system.  The  configuration  file  contains  information  about  the  events  and  rules  created  by 
the  DPE.  It  also  contains  information  about  the  class,  events  created  by  the  user  application. 
This  output  file  can  be  generated  either  in  XML  or  text  format. 

4.  IMPLEMENTATION  OF  THE  DYNAMIC  PROGRAMMING  ENVIRONMENT 

This  chapter  discusses  the  implementation  details  of  the  DPE.  It  is  organized  as  follows: 

Eirst,  the  data  structures  required  to  create,  modify  rules  and  create  events  are  discussed. 
Second,  parsing  of  input  files  in  both  formats  XML  and  TEXT  to  store  the  information  in  the 
data  structures  is  discussed.  Einally,  the  objects  created  to  represent  the  condition  part  of  the 
rule  and  to  handle  the  complete  information  about  the  rule  are  described. 
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4.1.  Data  structures  used  in  DPE 


The  information  from  the  eonfiguration  files  is  stored  in  the  following  data  struetures.  Some 
of  these  data  struetures  store  the  data  in  DPE-defined  objects.  These  objeets  belong  to  either 
“EventObject”  or  “AttributeObject”  elass. 

EventObject 

The  information  eorresponding  to  each  event  is  stored  in  an  instance  of  elass  “EventObject”. 
The  various  data  members  of  “EventObject”  are  shown  in  Table  1.  This  elass  is  used  to  store 
information  regarding  the  various  events  types.  The  possible  event  types  are: 

•  Class-Eevel  primitive  event 

•  Instanee-Eevel  primitive  event 

•  Composite  Event. 
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Table  1:  Data  members  of  EventObject  class 


Data  member 

Description 

SeventType 

Used  to  store  the  event  type 

SeventName 

Used  to  store  the  event  name 

SCreatedBy 

Used  to  differentiate  if  the  event  was  created  by  DPE  or  user 
application 

SE  vents  ignature 

Used  for  primitive  events  only.  It  is  the  method  signature  of  the 

event 

VecParamters 

Used  to  store  the  names  of  parameters  that  will  be  inserted  into 
the  parameterlist  when  the  primitive  event  is  raised 

SE  ventinstanc  cN  ame 

Used  for  instance-level  primitive  event  only.  It  is  used  to  store 
the  name  of  Eventinstance 

CompositeEventType 

Used  to  store  the  composite  event  operator. 

VecE  vents 

Used  to  store  the  constituent  events  of  a  composite  event 

The  various  composite  event  operators  permitted  are;  AND,  OR,  NOT,  SEQ,  PEEIS, 
PERIODIC,  PERIODIC  STAR,  APERIODIC,  APERIODIC  STAR. 

AttributeObject 

Complete  information  corresponding  to  each  attribute  is  stored  in  an  instance  of 
''AttributeObject'’  class.  The  data  members  of  the  "AttributeObjecf’  are  shown  in  Table  2 
The  various  types  of  attribute  that  are  currently  supported  are;  String  and  Numeric.  The 
sEventName  specified  would  correspond  to  name  of  an  event  that  is  associated  with  the 
attribute  and  an  instance  ot" EventObject’  corresponding  to  the  event  name  should  exist. 


Table  2  Data  members  of  AttributeObject 


Name 

Description 

sAttributeName 

Specifies  the  name  of  the  attribute 

sAttributeType 

It  specifies  if  the  type  of  the  attribute 

sAttributeUnits 

It  specifies  the  units  used  for  attribute 

sEventName 

It  specifies  the  name  of  event  associated  with  attribute 

Data  Structures 

The  list  of  data  structures  present  in  DPE  is  shown  below  in  Table  3.  The  data 
structures  are  described  below; 
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Table  3  :  Data  structures  present  in  DPE 


Data  structure 

Description 

htClass  InstanceNames 

This  is  used  to  store  the  Instance  names 
corresponding  to  each  class 

htlnstanccNames  InstanceObject 

This  is  used  to  store  the  object  provided  by  the  user 
application  corresponding  to  its  name 

htEvents 

This  is  used  to  store  an  event  name  and  the 
corresponding  “EventObject” 

htEvent  Domains  Types 

This  is  used  to  store  every  event  class  and  list  of 
available  events  types  in  the  corresponding  class. 

vecConditions 

This  is  used  to  store  all  the  available  conditions 
methods 

htAttributes 

This  is  used  to  store  all  the  available  attribute  of  all 
classes  and  the  corresponding  Attribute  Object 

htCondition  Domains  Types 

This  is  used  to  store  every  condition  class  and  the 
list  of  all  available  condition  methods  and  attributes 
for  the  class 

vecActions 

This  is  the  list  of  all  action  methods 

sMailServer 

This  corresponds  to  the  name  of  Mail  Server  used 
to  send  the  e-mail 

sEromAddress 

This  corresponds  to  the  Erom  address  used  to  send 
the  e-mail 

4.2.  Implementation  of  input  configuration  file 

The  input  configuration  file  is  required  by  the  DPE  to  provide  information  about  the  user 
application  to  create  rules  and  events.  Therefore  when  the  DPE  is  started,  the  location  of  the 
input  configuration  file  is  specified.  The  file  can  be  specified  in  either  in  Text/XME  format. 
The  structure  of  the  input  file  is  shown  in  the  Eigure  6. 

Parsing  of  XML  document 

There  are  two  types  of  XML  interfaces:  tree-based  (DOM)  and  event-based  (SAX.).  Event- 
Based  API  provides  a  simpler,  lower-level  access  to  an  XML  document.  It  is  possible  to 
parse  large  documents,  with  sizes  greater  than  the  system  memory  size.  Event-Based  APIs 
report  parsing  events  directly  to  the  application  through  callbacks.  Application  implements 
handlers  to  deal  with  events  and  constructs  a  data  structure  using  callback  event  handlers. 
The  various  events  are  specified  in  Table  4. 
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Table  4:  Events  defined  in  SAX  Parser 


Event 

Description 

Start  Document 

Invoked  when  the  beginning  of  the  document,  it  is  found  by  the 
parser 

End  Document 

Invoked  when  the  end  of  the  document,  it  is  found  by  the  parser 

Start  Element 

The  SAX  parser  will  signal  the  start  of  element  by  invoking 
startElementO  along  with  some  information 

End  Element 

The  SAX  parser  will  signal  the  start  of  element  by  invoking 
endElementO  along  with  some  information 

The  ''ReadXMLConfig'’'  class  handles  parsing  of  the  XML  file.  This  class  uses  a  Xerces  SAX 
parser  to  parse  the  file  and  extends  the  DefaultHandler  class.  The  DefaultHandler  Class 
provides  the  default  event  handler  methods. 

import  org. apache. xerces.parsers.SAXParser; 
import  org. xml. sax.*; 

To  use  the  Xerces  SAX  interface,  a  SAXParser  object  must  be  instantiated 
XMLReader  xr  =  new  SAXParser(); 

You  then  need  to  register  a  SAX  event  handler.  The  SAX2  API  now  includes  a 
ContentHandler  interface  (org.xml.sax.ContentHandler.)  This  interface  includes  callback 
methods  for  all  significant  parsing  events,  including:  start  and  end  of  document,  start  and  end 
of  elements,  and  character  data. 

xr.setContentHandler(this);  //  Register  the  event  handler, 
xr.setErrorHandler(this);  //  Register  an  error  event  handler 
xr.parse(new  InputSource(sEileName));  //  Parse  any  XML  file 

The  endElement  event  is  of  interest  to  gather  the  information  from  the  configuration  file.  The 
task  performed  by  the  parser  when  each  of  the  following  tags  of  the  configuration  file  is 
encountered  are  specified  below: 

ClassName:  When  this  tag  is  encountered,  it  specifies  the  name  of  the  class  whose  properties 
are  provided  in  the  configuration  file.  The  value  is  stored  temporarily  in  a  String  since  it  is 
required  for  most  of  initialization.  “Track”  is  an  example  of  a  class  name. 

InstanceName:  This  specifies  one  of  the  instances  available  for  this  class.  It  is  stored  in 
htClass_InstanceNames  as  a  part  of  the  value  corresponding  to  a  key  corresponding  to  the 
class  name.  The  value  is  a  vector  of  instance  names.  Eor  example,  for  the  class  Track,  the 
names  of  existing  instances  name  in  htClass  InstanccNames  are  “T7000”,  to  this  vector 
“T7001”  is  added.  Now  there  are  two  instances  “T7000”,  “T7001”  for  the  class  “Track” 

Attribute:  Information  corresponding  to  the  attribute  namely  its  name,  type  units  and  the 
event  associated  is  collected  and  stored  in  an  attribute  object.  This  attribute  object  is  added  to 
htAttributes  as  a  value  corresponding  to  a  key  formed  by  the  combination  of  the  class  name 
and  the  attribute  name.  Eor  example,  in  the  sample  configuration  file,  for  an  attribute,  the 
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following  information  “Speed,  Numeric,  mph,  SpeedEvent”  is  stored  in  an  attribute  objeet 
and  is  stored  in  htAttributes  as  a  value  for  the  key  “Track.  Speed”. 

ClassLevelPrimitiveEvent:  Consider  an  example  where  the  following  information 
“SpeedEvent,  void  setSpeedQ,  NewSpeed”  is  eolleeted  for  a  elass-level  event.  The 
information  is  parsed  and  the  eorresponding  information  about  the  event  name,  event 
signature  and  new  parameter  name  are  initialized  and  an  instanee  of  “EventObject”  is 
ereated  using  this  information.  The  event  type  is  assigned  the  value 
“ClassLevelPrimitiveEvent’’  and  “sCreatedBy”  parameter  is  assigned  the  value  “User”.  If 
eventType  eontains  a  value  “ClassLevelPrimitiveEvenC,  it  speeifies  that  the  information  is 
about  a  elass-level  primitive  event.  The  value  “User”  for  “sCreatedBy”  indieates  that  the  user 
ereated  the  event.  This  instanee  of  “EventObject”  ereated  is  stored  as  a  value  in  htEvents 
with  event  name  “SpeedEvent”  as  the  key.  Also,  from  the  htEvents_Domain_Types,  the 
value  of  the  key  corresponding  to  this  class  “Track”  is  retrieved.  The  value  is  a  vector  of  all 
events  contained  in  this  class  that  is  updated  with  this  event  name  “SpeedEvent”. 

InstanceLevelPrimtiveEvent:  The  information  provided  contains  the  same  set  of 
information  as  in  a  class-level  primitive  event,  but  also  has  an  additional  value  that  specifies 
the  name  of  event  instance.  Eor  example,  consider  “T7001,  T700 ITrackEvent,  void 
setTrackNumberQ,  NewTrackNumber”  as  the  data,  this  information  corresponding  to  the 
event  instance,  event  name  ,  event  signature  and  new  parameter  name  is  used  to  create  an 
“EventObject”.  The  event  type  is  assigned  “InstanceLevelPrimtiiveEvent”  and 
“sCreatedBy”  parameter  is  assigned  the  value  “User”.  This  value  of  event  type  would 
indicate  that  the  “EventObject”  specifies  the  information  about  an  instance  level  event.  This 
information  is  updated  in  the  htEvents  as  well  as  in  the  htEvents  Domains  Type  as 
mentioned  before. 

CompositeEvent:  The  information  specified  for  a  composite  event  is:  the  composite  event 
name,  the  composite  event  operator  and  the  list  of  constituent  events.  Eor  example 
“TrackNumberSpeedEvents,  AND,  TrackNumberEvent,  SpeedEvent  ”,  there  are  two 
constituent  events  namely  “TrackNumberEvent”  and  “SpeedEvent” .  This  information  is 
used  to  create  an  “EventObject”  and  the  event  type  is  assigned  a  value  “CompositeEvent’. 
The  parameter  “sCreatedBy”  is  assigned  a  value  “User”.  This  “EventObject”  is  updated  in 
the  hashtables-  htEvents  and  the  htEvents_Domains_Type. 

Condition:  The  information  retrieved  gives  the  details  about  the  method  signature.  This  is 
appended  to  the  class  name  and  is  stored  in  the  vector  “vecConditions”.  After  storing  in 
“vecConditions”,  it  is  stored  in  htCondition  Domains  types  corresponding  to  the  class.  Eor 
example,  “conditionTrackNumber”  is  the  method  signature;  it  is  updated  with  a  value 
“Track.conditionTrackNumber”  in  vecConditions  and  for  a  key  “Track”  in 
htCondition  Domains  types  as  specified. 

EventsCreated:  When  this  tag  is  encountered,  a  flag  is  set  indicating  that  any  further 
ClassEevelPrimitiveEvent  or  CompositeEvent  tags  encountered  would  have  the 
“sCreatedBy’’’  parameter  of  “EventObject”  set  to  “DPE”.  This  would  indicate  that  the  event 
is  created  by  DPE  and  define  the  events  in  EED. 
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MailServer:  This  specifies  the  address  of  the  mail  server  used  to  send  an  email  and  it  is 
stored  in  Constants. sMailServer.  For  example,  mail.uta.edu,  would  be  the  address  of  mail 
server. 

FromAddress:  To  send  an  email,  the  sender-address  needs  to  be  specified.  This  information 
is  specified  as  FromAddress.  This  value  is  then  stored  in  Constants. sFromAddress.  For 
example,  ” calvin@calvin_hobbes.com  ”,  would  be  the  email  address  used  to  specify  the 
sender  email-address 

RulesCreated:  This  tag  is  used  to  indicate  to  the  DPE  to  create  rules.  A  flag  corresponding 
to  this  tag  is  set  to  true  when  this  tag  is  encountered. 

ClassRule:  The  information  required  to  create  a  class  level  rule,  the  event  name, 
ActionObject  name.  Action  String,  ConditionObject  name,  ConditionString,  is  specified.  For 
example,  if  “NewSensorEvent,  nuii,  varakaia@omega.uta.edu,  nuii, 

Sensor. conditionSensorNumber”  is  given  as  the  information  of  a  required  class  rule.  The 
Condition  object  can  be  null.  Here  the  name  of  ActionObject  specified,  as  null  would 
indicate  to  the  DPE  to  use  the  default  action  provided  (i.e.,  email  as  the  action)  and  the 
condition  string  would  provide  the  destination  email  address.  If  the  action  object  name  is 
specified  then  it  is  used  to  create  the  rule.  After  all  the  information  is  collected,  it  is  stored  in 
an  instance  of  “GeneraiRuieObject”  and  then  a  call  to  EED  is  made  to  create  the  rule. 

InstanceRule:  Eor  an  instance  rule,  the  only  difference  from  class  level  rule  is  that  an  Event 
instance  is  specified  as  part  of  the  rule.  Eor  example,  consider  “Track.TJOOl,  SpeedEvent, 
T4001,  Track.action.,  nuii,  Track.dSpeed  increases  0  mph  &&  nuii,  Track.sTrackNumber  == 
T7001  TrackNumber” .  Here,  Track.TVOOl  corresponds  to  an  event  instance,  T4001 
corresponds  to  an  action  instance  name,  Track.action  is  the  action  method.  The  condition 
string  is  “Track.dSpeed  increases  0  mph  &&  nuii,  Track.sTrackNumber  ==  T7001 
TrackNumber”  and  the  condition  object  is  null.  The  rule  uses  an  action  method  for  the  action 
part  of  the  rule.  Once  all  this  information  is  collected,  it  is  stored  in  an  instance  of 
“GeneraiRuieObject” .  A  call  is  made  to  the  EED  to  create  the  instance  rule. 

The  text  Configuration  file  is  parsed  and  the  same  set  of  steps  is  performed  as  mentioned  for 
a  XME  file. 

4.3.  Implementation  of  Email  feature  as  default  action 

Email  is  provided  as  the  default  action  for  a  rule.  This  feature  is  implemented  using  Java 
Mail  API  provided  by  Sun  Microsystems.  Java  Mail  API  is  platform  and  protocol 
independent  mail/messaging  solution  [16].  In  DPE,  the  information  about  MailServer  and 
sender  address  is  stored  in  Constants. sMailServer  and  Constants. sEromAddress.  The  action 
part  of  the  rule  would  provide  the  “recipient  address”  for  the  email  and  the  message  would 
correspond  to  information  about  this  Rule  and  EistOfParameterEists  passed  to  action  by  the 
EED  during  rule  execution. 

A  class  “EmaiiCiient”  is  used  to  implement  the  feature  of  sending  email  and  is  similar  to  the 
sample  program  shown.  An  instance  of  this  class  is  created  for  action  part  of  every  rule  that 
chooses  email  as  the  action  and  is  also  assigned  the  recipient  address.  After  the  condition  of 
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Rule  evaluates  to  true,  the  sendEmail  method  is  invoked.  The  LED  passes  information  about 
the  '"ListsOfParameterLists  “ListOfParameterLists”  eontent  is  printed  as  the  message  along 
with  the  information  about  the  rule. 

4.4.  Implementation  of  Condition 

When  the  eondition  is  seleeted  for  the  rule,  it  ean  eonsist  of  many  simple  eondition  strings 
eonneeted  together  by  Boolean  operators.  “ConditionAetionGenerie”  elass  implements  the 
eomplete  eondition  string  and  internally  eontains  RuleConditionObjeet  that  implements  the 
simple  eondition  string. 


Table  5:  Data  members  of  RuleConditionObjeet 


Data  Member 

Deseription 

sClassName 

Name  of  the  elass  eontaining  the  attribute  or  eondition  method 

lobjeetType 

Type  of  eondition:  a  eondition  method  or  a  attribute 

sInstaneeName 

Name  of  objeet  eorresponding  to  this  eondition  part,  ean  be  null 

Oinstanee 

Referenee  to  eondition  objeet 

SMethodName 

Name  of  the  method  if  a  eondition  method  is  speeified  else  it  is 
equal  to  "eheek" 

S  AttributeN  ame 

Name  of  attribute  used  in  the  simple  eondition  string 

SAttributeType 

Type  of  the  attribute,  ean  be  either  NUMERIC  or  STRING 

sComparisionOperator 

Stores  the  eomparison  operator  used  in  attribute  based  eondition 

SComparisionUnit 

Stores  the  eomparison  unit  either  %  or  the  attribute  unit.  Used  in 
attribute  eondition 

SComparisionValue 

Stores  the  eomparison  value  used  in  attribute  eondition 

SEventSignature 

Event  signature  of  the  event  assoeiated  with  the  attribute  used 

sN  ewP  ar  ameterN  ame 

The  name  of  parameter  inserted  by  the  primitive  event  when 
raised 

4.4.1.  RuleConditionObjeet 

The  eomplete  eondition  ean  eontain  either  one  '"RuleConditionObjeet”  or  many 
"RuleConditionObjects  ”  eonneeted  by  operators  &&  and  ||.  This  "RuleConditionObjeet” 
elass  eontains  information  about  the  elass,  name  of  method  to  be  exeeuted  and  the  aetual 
parameter  to  pass  to  the  method.  The  data  members  are  mentioned  in  Table  5.  The  data 
members  are  designed  in  sueh  a  manner  that  the  modifieation  of  simple  eondition  string  ean 
be  easily  implemented.  The  important  member  funetions  are  speeified  in  Table  6.  The 
RuleConditionObjeet  uses  refleetion  method  in  Java  to  invoke  a  method  for  a  speeified 
objeet  along  with  the  aetual  parameters. 

4.4.2.  ConditionAetionGenerie  elass 
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The  “ConditionActionGeneric”  class  handles  the  condition  of  the  rule.  The  complete 
condition  string  is  broken  into  a  vector  of  “RuleCondtionObjects  ”  and  a  vector  of  Boolean 
operators. 

The  data  members  of  the  class  are  represented  in  Table  7.  The  important  member  functions 
are  represented  in  Table  8.  The  “ConditionActionGeneric”  class  has  a  method  "condition" 
which  is  specified  as  the  name  of  the  condition  method  while  the  rule  is  being  created.  This 
method  computes  the  final  Boolean  result  after  it  evaluates  the  result  from  each  of 
“RuleConditionObjects”  invoked  and  applying  the  corresponding  binary  operators. 


Table  6:  Member  functions  of  RuleConditionObject 


Method 

Description 

setClassMethodNames 

Initializes  the  class  name,  method  and  parameters 
required  for  attribute  condition 

setEventSignature  NewParamet 
erValue 

Used  to  initialize  the  event  signature  of  event 
associated  with  the  attribute,  new  Parameter  name  and 
the  attribute  type 

setMethodParams 

Initialize  the  object  instance,  actual  parameter  for  the 
method  “sMethodName”,  construct  the  compare  string 

invokcMethod 

Used  to  invoke  the  method  corresponding  to 
sMethodName  of  the  instance  object  using  Java 
Reflection 

compareValueString 

Used  to  simplify  the  special  comparison  condition 
string  into  one  using  the  normal  comparison 

Resetinstance  Conditionstring 

Used  to  modify  the  simple  condition  string,  it  compares 
the  new  class,  instance,  method  or  attribute  comparison 
string  and  updates  all  the  modified  parameters  and 
object  type  if  necessary 

Table  7:  Data  members  of  ConditionActionGeneric  class 


Data  members 

Description 

vecConditionObjects 

This  is  a  vector  of  RuleConditionObjects.  The  order  of 
elements  stored  in  the  vector  corresponds  to  the  order  as  in 
the  condition. 

vecOperators 

This  is  a  vector  of  Boolean  operators.  They  are  stored  in 
same  order  as  present  in  the  condition. 
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Table  8;  Member  function  of  ConditionActionGeneric  class 


Method 

Description 

initializeVectors 

This  method  is  invoked  when  an  instance  is  created. 

A  condition  string  provided  is  separated  into  two 
sets.  One  set  contains  the  “RuleConditionObjects  ” 
and  other  set  is  Boolean  operator. 

addT  ovecConditionObj  ects 

This  is  invoked  to  by  initializeVectors,  to  create 
RuleConditionObject  corresponding  to  each  simple 
condition 

condition(EistOfParameterLists 

paramlists) 

This  method  is  specified  as  the  condition  method  for 
every  rule  created  by  DPE.  EED  invokes  it  when  this 
rule  is  fired. 

modifyCondition 
(Vector  vecInstanceObjects, 
String  sConditionString) 

This  method  is  used  to  modify  the  existing  condition 
of  a  rule.  It  updates  the  two  vectors  with  the  new 
values  from  the  modified  condition. 

4.4.3.  Implementation  of  GeneralRuleObject 

“GeneralRuleObject”  class  is  used  to  store  the  information  of  a  rule  (i.e.,  Event,  Condition 
and  Action).  The  event  part  of  rule  consists  of  the  event  name  and  event  instance.  The 
condition  part  of  the  rule  is  instance  of  “ConditionActionGeneric  ”  class  and  the  action  part 
of  the  rule  consists  of  the  action  method  and  the  object  corresponding  to  that  action  method. 
Each  “GeneralRuleObject”  is  stored  as  the  value  corresponding  to  the  name  of  the  rule, 
which  is  a  key  for  Constants.htRuleName  GeneralRuleObject.  The  data  members  of  the 
GeneralRuleObject  are  as  shown  in  Table  9. 


Table  9:  Data  members  of  GeneralRuleObject 


Data  members 

Description 

sEventName 

The  name  of  event  specified 

sEventInstanceName 

The  name  of  event  instance  specified 

conditionActionGenericInstance 

Condition  of  the  rule 

sAction 

The  action  method 

sActionInstance 

Name  of  action  instance  specified 

The  information  about  a  rule  is  stored  in  an  object  so  that  the  condition  part  of  the  rule  can  be 
accessed  later  for  modification,  and  also  to  keep  track  of  the  information  of  the  various  rules 
created.  After  the  “GeneralRuleObject”  is  stored  in  the  hashtable,  the  “createRule”  API  of 
EED  is  called  to  create  the  rule. 

4.5.  Mechanism  in  DPE  that  responds  to  when  a  rule  is  triggered  in  EED 
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When  an  event  is  raised,  the  rules  assoeiated  with  it  are  triggered  in  the  LED.  When  a  rule  is 
triggered,  the  eondition  is  evaluated.  Here  the  eondition  is  an  instanee  of 
“ConditionGeneric  ”  elass.  The  “condition  ”  method  of  this  objeet  is  invoked  and  the  LED 
passes  “ListOfParameter Lists  ”  as  the  argument.  This  method  ealls  the  “invoke  ”  method  of 
eonstituent  “RuleConditionObjects”.  When  the  “invoke”  method  is  exeeuted  then  the  objeet 
instanee  within  the  “ RuleConditionObject”  invokes  either  the  eondition  method  or  evaluates 
the  attribute  eomparison. 

4.5.1.  Assigning  the  Objeet  Instanee  in  “RuleConditionObject” 

The  “objeetinstanee”  data  member  in  “RuleConditionObject”  ean  either  be  a  null  objeet  or  a 
speeifie  objeet.  When  a  null  instanee  is  speeified  in  the  SCS  as  the  objeetinstanee,  an  objeet 
instanee  needs  to  be  assigned.  When  the  event  is  raised,  the  objeet  that  raises  the  event  is 
passed  as  a  part  of  the  parameter  list.  The  number  of  parameter  lists  passed,  in 
“ListOfParameterLists  ”  would  depend  on  the  number  eonstituent  events.  The 
“ListOfParameterLists  ”  is  passed  onto  to  “RuleConditionObject”  from  the 
“ConditionGeneric  ”  elass.  Now  depending  on  the  eondition  type  i.e.  a  method  or  an 
attribute,  it  is  handled  differently. 

The  pseudoeode  is  shown  below  for  assigning  the  “objeetinstanee”  in  the  Rule 
ConditionObjeet 


Line  1  :  RuleConditionObjeet.setMethodParams(ListOfParameterLists  pLists) 
Line  2  :  {  If(ConditionType  ==  ConditionMethod)  { 

Line  3  :  methodParams  =  pLists 

//Assigning  the  formal  parameter  required  by  the  eondition  method 
Line  4  :  If(instanee  ==  null){ 

Line  5  :  if(pLists.size  ==  1) 

Line  6  :  instanee  =  pLists. getLirst().getEventInstanee(); 

Line  7  :  else{ 

Line  8  :  If(ConditionType  ==  ConditionMethod)  { 

Line  9  :  instanee  =  pLists. getLirst().getEventInstanee(); 

Line  10  ;  }else{ 

Line  1 1  :  Get  the  event  signature  of  the  event  assoeiated  with 

attribute 

Line  12  :  if(eventsignature  exists  in  parameterList2  of  pLists) 

Line  13  :  instanee  =  parameterList.  getEventInstanee(); 

Line  14  ;  else 

Line  15  :  instanee  =  pLists. getLirst().getEventInstanee(); 

Line  16  :  ereate  the  CompareStringO 

}  //  end  of  ConditionType  ==  attribute 
}//  end  of  outer  else  } 


4.5.2.  Condition  Method  used  as  Condition  String 


A  method  of  a  elass  to  be  used  as  a  eondition  method  of  a  SCS  should  have  an  argument  of 
type  “ListOfParameterList”  and  return  a  Boolean  value  aeeording  to  the  design  speeified  by 
LED  for  eondition  part  of  the  rule.  When  the  “invoke”  method  of  a  eonstituent 
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“RuleConditionObject”  is  executed  and  this  would  in  turn  execute  the  selected  condition 
method  on  the  '"objectlnstance”  in  “RuleConditionObject” .  The  result  from  this  method  is 
passed  on  to  corresponding  “ConditionGeneric”  object’s  condition  method. 

4.5.3.  Normal  Comparison  Operators  used  with  Attributes 

An  attribute  of  a  class  can  be  used  as  a  part  of  the  SCS  only  if  the  class  is  derived  from  the 
“Reactive”  class  present  in  the  LED  package.  The  attribute  should  be  a  public  member  of  the 
class. 

Currently  only  two  types  of  attributes  are  supported;  string  or  numeric.  This  is  because  of 
the  limitation  of  regular  expression  evaluator  used  by  the  “eval”  method  of  the  “Reactive” 
class,  to  compute  the  result  of  comparison  string.  To  this  method  an  attribute  name  along 
with  normal  comparison  operators  and  comparison  value  is  passed.  This  method  replaces  the 
attribute  with  its  value  at  run  time  and  uses  the  evaluator  to  compute  the  result.  Hence  the 
restriction  on  the  attribute  that  it  has  to  be  a  public  member  of  the  class,  so  that  it  can  be 
accessed  directly.  The  result  of  the  evaluator  is  a  Boolean  object,  whose  value  is  returned  by 
the  “eval”  method.  Examples  of  some  of  the  operators  supported  normally  by  the  regular 
expression  evaluator  in  the  eval  method  are: 

•  “null  ,Track.TrackNumber  ==  “T7000”  TrackNumber” 

•  “null,  Track.Speed  >=  7000  miles“ 

In  the  above  examples,  only  the  string  containing  the  attribute  name,  comparison  operator 
and  value  are  passed  as  the  argument  to  the  “eval”  method  of  “RuleConditionObject” .  The 
string  passed  for  some  of  the  above  examples  would  be 

•  TrackNumber  ==  “T7000” 

•  Speed  >=  7000 

4.5.4.  Special  Comparison  Operators  with  Attributes 

When  the  special  comparison  operators  are  used,  the  SCS  has  to  be  altered  in  such  a  manner 
that  the  same  “eval”  method  could  be  used  as  in  the  case  of  normal  condition  comparison 
operators.  But  before  changing,  reference  to  the  new  attribute  value  of  the  object  is  required. 

To  achieve  this,  “EventObject”  corresponding  to  this  attribute  is  retrieved.  After  the 
corresponding  “EventObject”  is  retrieved,  the  name  of  the  parameter  that  has  been  inserted 
into  the  “ParameterList”  when  the  event  was  raised  is  extracted.  The  value  of  the  parameter 
would  be  the  new  value  and  the  old  value  of  the  attribute  is  obtained  from  the  object  at  run 
time  from  “ParameterList” .  The  value  corresponding  to  the  assigned  parameter  name  is 
extracted  from  the  “ParameterList” .  This  value  is  substituted  in  the  SCS  and  the 
corresponding  arithmetic  operations  are  performed  and  the  result  is  computed  and  compared 
to  the  attribute.  This  SCS  is  now  in  a  format  similar  to  the  SCS  containing  normal  condition 
operator.  This  new  SCS  is  used  when  the  “eval”  method  of  the  “EventObject”  is  invoked 

4.5.5.  Computing  the  result  of  condition  after  evaluation  of  constituent  SCS 
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The  “  ConditionGeneric”  object  needs  to  compute  the  result  of  the  condition  from  the 
constituent  SCS  and  needs  to  apply  the  Boolean  operators  in  the  same  order  as  specified  in 
the  condition.  The  pseudocode  is  shown  below: 

Line  1  :  Boolean  condition(ListOfParameterLists  pLists) 

Line  2  :  {  result  = 

Line  3  :  j  =  0;i  =0; 

Line  4  :  for(i  <  vecRuleObjects.sizeQ  ){ 

Line  5  :  object  =  vecRuleObject.get(i) ; 

//Get  the  i**'  RuleConditionObject  from  vecRuleObject 
Line  6  :  object.  setMethodParams  (pLists); 

//Execute  the  method  and  pass  pLists  as  the  actual  parameter 
Line  7  :  result  =  result  +  object. invokeO; 

//Append  the  result  from  invoke  method  when  it  is  executed 
Line  8  :  if(j  <  vecOperatorss.size()  ){ 

result  =  result  +  vecOperators.get(j); 

//Get  the  j**'  Boolean  operator  from  vecoperators  and 
append  it  to  result 

j++;  } 

} //Evaluate  the  string  and  return  Boolean  result 
Eine  9  :  return  eval(result);  } 


4.6.  Rule  Modification 

When  the  new  condition  string  is  received  from  the  user,  it  is  passed  to  the  corresponding 
instance  of  “ConditionGeneric”  class,  which  in  turns  sends  it  the  “RuleConditionObject”. 
The  pseudocode  for  handle  the  modification  of  SCS  in  a  “RuleConditionObject”  is  shown 
below: 

Eine  1 :  void  resetlnstance  ConditionString  (sNewClassName, 
sNewInstanceName  ,  sNewMethod_AttributeName) 

Eine  2:  {  Eind  the  type  of  new  condition  string  and  assign  it 
newConditionType 

Eine  3:  if  (oldConditionType  ==  new  ConditionType){ 

Eine  4:  if(oldConditionType  ==  Attribute) 

Eine  5:  {  Compare  and  Update  values  that  have  changed 

Eine  6:  if(attribute  changed) 

Eine  7:  {  update  the  newParameterName  and 

events  ignature} 

EineS:  }else{  //ConditionType  ==  Method 

Eine  9:  update  the  method  name 

}//end  of  inner  else 

Eine  10:  }  else  {//condition  has  modified  from  an  attribute  to  method  or  vice  versa 

Einel  1 :  Update  classname  Method  or  Attribute,ConditionType,  InstanceName 

}//end  of  else 

Emel2:  if  (mstance!=  newInstanccName) 
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Linel3: 

} 


update  the  instanee  name 


5.  CONCLUSION  AND  FUTURE  WORK 

5.1.  Conelusion 

This  paper  proposes  an  interaetive  approaeh  for  supporting  the  ereation  of  rules  and  events 
dynamieally  at  run  time,  whieh  is  eritieal  for  several  monitoring  applieations  using  LED.  It 
aehieves  this  without  reeompiling  and  restarting  the  applieation.  The  DPE  provides  a  generic 
set  of  classes  to  handle  creation,  management,  and  execution  of  rules.  This  set  of  classes  is 
application-independent  making  the  system  useful  for  any  application.  The  user  application 
provides  the  necessary  class  and  event  information  to  the  DPE  through  a  configuration  file. 
The  DPE  uses  this  information  to  create,  modify  and  manage  rules.  The  DPE  supports 
creation  of  new  composite  and  temporal  events.  Also,  a  default  action-  sending  email  is 
provided.  A  user-friendly  interface  is  provided  to  perform  these  tasks. 


5.2.  Eimitation  and  Euture  Work 

The  DPE  proposed  in  this  paper  only  supports  creation  of  new  temporal  and  composite 
events.  It  does  not  support  the  creation  of  new  primitive  events.  It  is  possible  to  accept  a 
method  that  corresponds  to  EED  specifications,  compiles  the  code  programmatically  and 
loads  it  at  runtime.  Modification  of  an  existing  event  may  require  a  custom  class  loader,  as 
the  default  Java  class  loader  does  not  seem  to  reload  an  existing  method. 

Current  configuration  input  does  not  specify  details  of  the  GUI.  One  extension  would  be  to 
generalize  the  GUI  and  make  it  customizable  for  each  application  by  accepting  some  layout 
and  form  information.  It  would  also  be  useful  to  support  application  specific  graphics  in 
addition  to  the  rule  editor  on  the  screen.  In  addition  to  EED,  we  have  a  global  event  detector 
(or  GED)  [17]  that  can  be  used  for  distributed  applications.  Rules  can  be  defined  using  events 
in  one  or  more  applications.  It  is  also  possible  to  combined  local  and  global  events  into 
composite  events.  A  similar  interactive  rule  editor  for  supporting  distributed  environment 
would  be  useful. 
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